-
Notifications
You must be signed in to change notification settings - Fork 361
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: Controller handle Hook errors #7081
Conversation
esti/hooks_failure_test.go
Outdated
branches: | ||
- * |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think you can pass empty list []
var hookAbortErr *graveler.HookAbortError | ||
if errors.As(err, &hookAbortErr) { | ||
log.WithField("run_id", hookAbortErr.RunID).Warn("aborted by hooks") | ||
cb(w, r, http.StatusPreconditionFailed, err) | ||
return true | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The HookAbortErr can hold (wrapped by graveler.ErrPreconditionFailed), so the default handler implementation will return http.StatusPreconditionFailed
.
All is left is the logging which I think we should keep in all places we trigger hooks and not in the central location.
My two concerns are:
- logging related to the operation, today we capture run_id tomorrow we will need the full content (ex: source branch and etc)
- the downside in having central error location is we can't map where this error is being used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- HookAbortErr already wraps the underlying error from the hook execution.
- Logging is coupled with checking that we actually had a HookAbortErr which brings us back to exactly the same situation where we were - missing handling because we forgot to add the same code block in another operation that uses hooks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Closes #7075
Change Description
Background
Some operations handled pre hook failures returning the appropriate error code and some operations (such as create branch) did not handle HookAbort Errors and as a result server returned 500
Bug Fix
Fixed by moving the hook error handling to a central location under
handleAPIError
Testing Details
Added new system test to cover the scenario